Mcdc test coverage - part 7 - #11222

…_init_multi never built

…ards from the white-box

…C/DC rows

…n SigsLeft guard

…y unused

Their callers sit behind differing feature guards, so any configuration can
compile in none of them.

Also guards the sni free helper on HAVE_SNI and gives the request-direction
key share entry a public key before it is written.

EXPECT_DECLS records the failure and carries on, so the field access ran on
a null pointer.

The test builds a server context but its response-direction sections need a
client one; guarding the sections keeps the server half running.

A build without a client compiles out its only user.

ExpectNotNull() does not assign once an earlier expectation has failed, so
the variable can be read undefined. Also moves the server-context helper's
declarations to the top of its block.

…he paths

wolfSSL_SetAllocators is defined only under USE_WOLFSSL_MEMORY, the session
ticket members only under HAVE_SESSION_TICKET, and the ffdhe bookkeeping that
makes an unsupported group parse cleanly is compiled out without DH, TLS 1.2
or the server.

The tests/unit-mcdc white-box translation units are not part of unit.test, so
nothing in CI builds or runs them. This builds --enable-all once and runs the
subset that works against it, failing only when one that passed before stops.

Cover the RFC 4518 Sec. 2.2 ranges that map a code point to nothing, the
EN QUAD to HAIR SPACE block, UTF-16 surrogate pairs and the code units
just above the surrogate block, values whose tag is not a character
string type, and the AttributeTypeAndValue argument validation in
MatchDirAttr().

The chain check tells RSASSA-PSS apart from SHA-1 through the algorithm
parameters rather than the signature OID, which no existing case covers.

Adds the ecdsa-with-SHA1, dsa-with-sha1 and RSASSA-PSS signature algorithm
vectors, the certificate and chain presence guards of CheckCertChainSigAlgo(),
and the allocation failure SendTls13Certificate() has to pass through.

… stack

wc_AesNew accounts for the type's alignment, which was the reason for the
local; the local was large enough to push the function's frame past 4096
bytes in some configurations.

The caller-supplied Aes was moved to wc_AesNew() to keep aeskeywrap_test()
under the 4096 byte frame limit, but wc_AesNew() allocates with XMALLOC and
so only guarantees the platform malloc alignment: 8 bytes on 32-bit targets,
against the 16 that struct Aes asks for through its ALIGN16 members. On
32-bit ARM built for armv8-a+crypto, wc_AesSetIV() lowers to an
alignment-qualified NEON store, which faults on an 8-aligned object.

Move the block to its own function instead. The Aes goes back to a local, so
the compiler gives it the type's alignment, and the frame limit is per
function, so aeskeywrap_test() stays within it.

The previous commit moved the caller-supplied Aes into its own function to
keep the frame down, which does not work: with --enable-aesgcm=table the GCM
tables inside struct Aes are 4096 bytes on their own, so no function can hold
one as a local under the -Wframe-larger-than limits CI enforces (4096 in the
aes config set, 2048 in the small-stack and linuxkm workflows). -Wstack-usage
counts the whole call chain in any case, so splitting the function would not
have helped even had the frame fit.

Plain heap allocation does not work either. The type asks for 16 byte
alignment through its ALIGN16 members, while XMALLOC -- and so wc_AesNew() --
only guarantees 8 on 32-bit targets, and wc_AesSetIV() lowers to an
alignment-qualified NEON store when building for armv8-a+crypto.

Allocate with headroom and align by hand, keeping the base pointer for XFREE.
That satisfies both constraints: the frame holds only pointers, and the object
meets the alignment its type declares.

… 32-bit ARM

struct Aes carries ALIGN16 members, so _Alignof(Aes) is 16 whenever
WOLFSSL_USE_ALIGN is set, which is the default on ARM: --enable-aligndata
defaults to yes, and WOLFSSL_ARMASM defines WOLFSSL_USE_ALIGN unconditionally.

The objects are heap allocated with XMALLOC on the TLS data path -- SetKeys()
does so for every AES suite, as do dtls13.c, internal.c and kdf.c. On 32-bit
targets malloc only guarantees 8 byte alignment, so an object can come back
8-aligned while its type claims 16. That is undefined, and observable:
wc_AesSetIV() lowers to an alignment-qualified NEON store on armv8-a+crypto,
which faults.

Observed on arm-linux-gnueabihf under qemu-arm with --enable-armasm: a TLS 1.3
AES-CCM handshake took SIGBUS in key setup, with the encrypt object 16-aligned
and the decrypt object 8-aligned. Which object lands where follows from
allocation history, so the fault migrates between call sites rather than
belonging to any one of them.

Cap the request at what the allocator guarantees, as the __ICCARM__ case above
already does for the same reason. The wolfCrypt KAT suite and the rsa, ecc and
dh unit test groups stay green on that target, so the hand-written ARM assembly
does not rely on the wider alignment.

…antee on 32-bit ARM"

This reverts commit 0cccfc5.

The cap applies to WOLFSSL_ALIGN(x) as a whole, so it degrades every ALIGN16,
ALIGN32 and ALIGN64 declaration on 32-bit ARM, not just the ones that are heap
allocated. That includes buffers whose alignment is a hardware requirement
rather than an optimisation: Aes.keyInit is ALIGN64 (aes.h) and
ecc_key.keyRaw is ALIGN32 (ecc.h), both used for DMA on Xilinx targets, and
WOLFSSL_XILINX force-enables WOLFSSL_USE_ALIGN (types.h). Silently lowering
those is worse than the fault it was meant to avoid.

The underlying defect is real and stands: struct Aes declares 16 byte
alignment through its ALIGN16 members, while the objects are allocated with
XMALLOC, which guarantees only 8 on 32-bit targets. The fix belongs in the
allocation path, not in the type's declared alignment.

wolfSSL_Malloc_cb, wolfSSL_Free_cb and wolfSSL_Realloc_cb have four different
signatures in memory.h, selected by WOLFSSL_STATIC_MEMORY and
WOLFSSL_DEBUG_MEMORY: the static-memory forms take a heap pointer and a type,
and the debug forms take the caller's function and line. The counting
allocators these tests install are written to the plain (size) form, so
wolfSSL_SetAllocators() does not compile once either macro is defined --
--enable-staticmemory fails the build outright.

Guard them the way tests/api.c already guards der_cap_malloc_cb, on
!WOLFSSL_STATIC_MEMORY && !WOLFSSL_DEBUG_MEMORY. test_pkcs7.c had the
static-memory half and needed only the debug half.

Builds clean now under --enable-staticmemory --enable-all, under --enable-all
with WOLFSSL_DEBUG_MEMORY, and unchanged under plain --enable-all.